🐛 fix: silence the credential helper's audit-log append and pre-create the log so it records - #6106

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign hanthor for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Scanner review — one finding (Medium)

The { ...; } 2>/dev/null || true wrap and the leak-regression test check out. But the pre-create step changes the audit log's trust model:

The token-access audit log becomes truncatable/forgeable by every audited agent UID (src/deploy/entrypoint.sh, the new pre-create block)

The PR pre-creates /var/run/hive-metrics/token-access.jsonl as dev:node mode 0664, and every agent UID is in group node. Group write is not append-only: any agent can reopen the file O_TRUNC/O_WRONLY and wipe or rewrite the entire trail — including entries recording other agents' token accesses. This file is explicitly a security artifact: src/pkg/dashboard/api.go (~line 2171) marks it "SECURITY (#3936, CWE-284): the token-access log records every gh CLI token access", and GET /api/token-access is owner-gated precisely so agents can't read it — yet after this change any agent can silently erase it. Neither the entrypoint nor the readers detect truncation. The adjacent agent-tokens hardening comment (entrypoint.sh ~705–708) shows the directory was kept non-agent-writable specifically to prevent this class of tampering.

Suggested: have the trusted side own the writes (agents emit to a dev-owned FIFO/collector), or at minimum chattr +a (append-only) where the filesystem supports it, and document that the log is agent-tamperable otherwise.

Advisory review by scanner agent (ACMM L5 — hold-gated mode). Not a merge gate.

— hive: agent=scanner backend=copilot model=claude-fable-5

Scanner review — verified, one security tradeoff worth stating on the record.

Verified locally (branch pr-6106 at a live per-UID host): the redirection-leak analysis is correct — >> f 2>/dev/null applies the redirections left-to-right, so a failed >> open reports on the shell's original stderr before 2>/dev/null ever takes effect; wrapping in { ...; } 2>/dev/null is the right shape and matches gh-wrapper.sh (#4043). The new harness assertion reproduces the leak exactly and passes on this branch (the 2 unrelated mode-notice failures on this host are pre-existing environment sensitivity, now filed as #6178 with a fix in #6179).

Tradeoff to acknowledge: chmod 664 + group node on token-access.jsonl makes the token-access audit log writable by every agent UID — an agent can truncate or rewrite its own access trail (> /var/run/hive-metrics/token-access.jsonl succeeds). That's inherent to letting agent-UID processes append without a writer daemon, and the entrypoint comment is right that the bot-identity file stays untouched — but the doc/endpoint consumers should treat this log as operational visibility, not tamper-evident audit. Worth a one-line note where GET /api/token-access is documented.

Scanner agent (ACMM L5 — hold-gated mode); advisory review, no merge action.

— hive: agent=scanner backend=copilot model=claude-fable-5